1. Field of the Invention
The present invention generally relates to user interfaces to simulation software and, more particularly, to a process that takes converted system software code as input to a program created with a commercial compiler to produce a simulated Operator System Interface.
2. Background Description
In modern, highly integrated aircraft there normally is found a complicated Operator System Interface (OSI) utilizing both a programmable keyset and multi function display (MFD). For example, the Multi-Mission Helicopter (MMH) employs I/0 (input/output) devices such as programmable keysets and Multi Function Displays. In the MMH it is necessary to program both keyset layering and requisite menus for system and menu control. Specific keys access menus, other key layers or functions. Other aircraft system solutions could use a combination of an application specific softkey hierarchy and Central Display Unit (CDU) for data entry and system control, but the basic approach would not be changed.
In the past, a great deal of computer code had to be written to create and maintain these functions, and changes were expensive as the design moved through the development process. In order to achieve accurate representation of the operational system, extensive emulation was needed, or actual source code had to be used. Without simulation, or emulation in some form, Control and Display (C&D) software development can be imperfectly matched to end objectives since intricate keyset and window moding (e.g., displaying different modes on the MFD where different modes display different graphics, menus, etc.) and behavior is not evaluated until the software is in its final stages.
Previously, much of control and display (C&D) software development was forced to rely on anecdote and word of mouth to determine fit and function relating to the user's requirements. Currently, the lack of specific written guidance on window moding and behavior exposes the likelihood that an imperfect interpretation of a C&D system will be made (i.e., actual requirements not detected early in development). This is inherently counter-productive to the end objective. This lack of an easy ability to prototype the OSI often results in the final coded system that does not fully correspond to, or map to, the users' requirements.
During the build up to Airborne Low Frequency Sonar (ALFS) solo flight testing, there are unique aircrew training requirements in order to prepare crews for the first flight, and likewise, follow-on development testing (DT) and operational testing (OT) will generate very similar needs. Because OSI proficiency is expected to be quite perishable, a basic simulator is required to maintain an adequate knowledge level between the initial training and actual flight events. With the transition to new keysets, and the conduct of ALFS solo flight test using the legacy keyset and DT/OT with production models, it is important to maximize the ease and efficiency with which the program converts between old and new versions.
The Controls and Display (C&D) interface is complex with intricately interwoven moding, behaviors and functionality. The OSI Trainer is required to refresh those skills that are needed to complete the intended testing schedule. In order to maximize the refresher training value a representative, graphical, interactive tool is required. It must be easily upgraded to stay abreast of frequent design changes in a dynamic developmental environment.